When using the default release-it changelog generator, I can specify a tag using the --git.tagMatch and --github.tagMatch arguments, and the generated changelog then includes commit messages since the specified tag.

However, when using the @release-it/conventional-changelog plugin, these arguments only control which tag is linked in the changelog headers; they do not control which commit messages appear in the changelog. Only the messages from the most recent semver tag to HEAD are included.

This is the expected behavior from conventional-changelog when it is called the way it is from @release-it/conventional-changelog, with previousTag in the context. The conventional-changelog-core documentation links to the conventional-changelog-writer docs, which say that the context parameter contains "Variables that will be interpolated to the template." This means that the context parameter only defines what shows up in the templated lines of the changelog; it does not affect which commit messages are selected for inclusion. The parameter which controls which commit messages are selected is gitRawCommitsOpts.

To make @release-it/conventional-changelog behave the same way as the default release-it changelog generator, it would be necessary to pass from in gitRawCommitsOpts. Here is a patch that does so.

Alternatively, a workaround is to select the previous tag before running release-it, then invoke release-it with the necessary parameters:

release-it \
  --git.tagMatch="${PREVIOUS_TAG}" \
  --github.tagMatch="${PREVIOUS_TAG}" \
  --'plugins.@release-it/conventional-changelog.gitRawCommitsOpts.from'="${PREVIOUS_TAG}"

It seems to me that @release-it/conventional-changelog ought to behave the same way as the default release-it changelog generator, and use previousTag when selecting the commit messages.

If instead it is intentional that it behave like conventional-changelog and only use the previousTag in the changelog headers and not when selecting the commit messages, then I think that this ought to be noted clearly in the documentation (with the above workaround if possible).